The present invention relates to a database load distribution processing method distributing database access loads, a device for the same, and a recording medium recording a program for the same. More specifically, in a distributed database access environment where a plurality of server systems is connected to a client system via a plurality of communication lines, the present invention relates to a technology that can be effectively applied to a database load distributing system that performs load distribution using transactions that execute distributing functions.
In conventional distributed database systems that use multiple servers, processing efficiency is improved by applying load distribution based on individual transaction processing programs and application programs. Japanese laid-open patent publication number Hei6-110850 describes a load distribution method for an on-line system that performs load distribution, where individual application programs serve as load distribution units. In this method, processing is assigned to the computer system in the network having the lowest load for the particular application program.
Also, in conventional distributed database systems, user application programs (UAPs) are written with a built-in retry function that attempts a retry operation when a transaction error event is detected. Thus, if a transaction is executed and result in an error, this indicates that there was a failure in the resources being used or that the resource is inactive, and this transaction is attempted again through the retry function described above.
Furthermore, in conventional distributed database systems, past transaction processing results are output to files to serve as transaction statistics information. This information is edited and analyzed manually to determine the number of distributing function processing paths. This distributing function processing path number is used for processing transactions, thus improving throughput for the next transaction.
In order to distribute transaction loads in a communication/server system available for transaction loads so that a distributed transaction throughput can be maintained, detection and management of active status and load status must be possible in real time for the communication and the server system. Not only must there be unified management of load usage for the multiple system resources needed for distributed database processing and load distribution of individual resources, but also system resource allocations must be performed so that the desired distributed database transaction processing efficiency can be achieved.
However, the conventional distributed database systems that use multiple servers do not perform unified management of a plurality of system information (e.g., loads on the communication environment needed for distributed database processing, loads on the CPU performing server processing, and server transaction processing loads) to allow selection of optimal execution resources on the basis of experiential values and the like. Thus, even in an execution environment where there are multiple communication resources and transaction processing servers, transaction loads are not distributed. This means that loads can be concentrated on specific processing resources, resulting in increased wait times for processing. This decreases transaction throughput and makes it difficult to provide a transaction performance for the total distributed database that takes advantage of the system environment.
Also, in conventional distributed database systems, the UAPs are written with built-in retry function for detecting transaction error events and attempting retries. This requires extra effort when developing UAPs to provide retry functions. Furthermore, when a failure takes place in a distributing function processing path, the inactivity/failure status for the resource being used must be determined and an alternate path must be set up or selected in order to minimize effects on the execution of other transactions. However, in the retry function described above, the UAP performing the retry operation first recognizes the inactivity/failure status when the executed transaction returns an error. Thus, when a failure takes place, transaction error events will take place repeatedly until all the UAPs recognize the inactivity/failure status. This will decrease transaction throughput.
In distributed database systems, the distributing function execution resources must be tuned according to dynamic changes in the execution environment resulting from changes in the nature of operations and increases in transaction volume. However, in the conventional distributed database system described above, a target transaction throughput is implemented through a distributing function processing path resource number determined by editing and analyzing information based on the results of past transaction processing, which had been output as a file to serve as transaction statistics information. As a result, communication and server resource numbers cannot be automatically assigned according to increases in transaction volumes that accompany dynamic fluctuations in operations traffic.
The object of the present invention is to overcome the problems described above and to provide a technology that makes it possible to prevent reductions in transaction throughput caused by load concentration on specific communication resources and server resources.
Another object of the present invention is to provide a technology that makes it possible to prevent reductions in transaction throughput caused by multiple transaction execution errors that take place when retry operations are performed in response to when a failure, as well as to eliminate the need to have transaction retry functions built in to UAPs.
Yet another object of the present invention is to provide a technology that makes it possible to reduce the number of steps required for resource tuning by eliminating the process of acquiring, editing, and analyzing transaction statistics for the purpose of determining a processing path number during execution of distributed transactions.
In a database load distribution processing system that distributes the load for accesses to a distributed database managed with a plurality of servers, the present invention performs load distribution for database accesses based on information indicating communication status and server status.
In a communication status management process module of the database load distribution processing system according to the present invention, communication resource failures, load, and activity status are monitored and communication status is managed. In a server status management process module, server failure, load, and activity status are monitored and server status is managed.
A distributing function path selection accesses information indicating communication status and server status and sets up a selection priority for each of the distributing function processing paths on the basis of priority settings guidelines. When a transaction processing request takes place, a distributing function processing path is indicated to a distributing client based on the selection priority settings, and the distributing clients uses the indicated distributing function processing path to request transaction processing.
If there is a failure in a communication resource or a server, an alternated path management process module determines the distributing function processing path in which the failure took place and sets up the path having the highest selection priority as an alternate path. If a transaction was being processed using the path on which the failure took place, the transaction that generated the error due to the failure is retried using the alternate path.
A path selection learning process module compares current transaction volume to load distribution statistical information data, which indicates past transaction processing results, and determines a distributing function processing path number. Resource usage is then optimized by changing the current processing path number to the distributing function processing path number determined above. For each of the optimized distributing function processing paths, transaction processing times, which indicate the processing times required for transaction processing, are recorded.
A distributing function path selection management process module uses information indicating communication status, server status, and transaction processing times to set up selection priorities for each of the optimized distributing function processing paths. These selection priority settings are used to indicate a distributing function processing path to the distributing client.
With a database load distributing processing system according to the present invention as described above, the load from distributed transaction requests can be distributed over a plurality of communication resources and server resources based on communication status and server status. This makes it possible to prevent transaction throughput reductions caused by concentration of load on specific communication resources and server resources.